『Team Geek』
https://images-na.ssl-images-amazon.com/images/I/41SlY0zvpKL._SX350_BO1,204,203,200_.jpg https://www.amazon.co.jp/dp/4873116309
本を手にとった動機
チーム開発に参加するときの心得を得ようと思い、手にとった 本で印象に残ったところの感想
1章 天才プログラマの神話
君が確実にコントロールできる変数を取り上げたい。君自身だ。 (p.3)
プログラマっぽくていい言葉
他者がわたしになにをしてくれるかではなく、わたしが他者になにをできるかを考え、実践していきたいのです。
君は天才じゃない。 (p.7)
これもまたいい言葉
何事もありのままの自分を受け入れるところから始まる
君は君の書いたコードではない。 (p.21)
2章 素晴しいチーム文化を作る
チームの文化の定義・維持・防御に責任を持つのはチームメンバー
少し驚いたけど、メンバーが主体的に作り上げたものでないと機能しないなぁと、とても納得した
前向きな批判をしてくれる友達や同僚を見つけたら、貴重な存在なので手放さないようにしておきたい
常々そう思う
3章 船にはキャプテンが必要
標準的なエンジニアしか採用しないなら、職場を変えたほうがいい
転職の際に「未経験者歓迎」をしている企業を避けたいのはこれが理由。
5章 組織的操作の技法
防御的な仕事によって、プロダクトの保守性・安定性・信頼性は高まる。だが、政治的な信頼性を獲得することはできない。防御的な仕事ばかりしていては、プロダクトが動いていないと思われる。
技術的負債がどれだけあっても、防御的な仕事に時間や労力の1/3~1/2 をかけないというルールを作っている。それ以上は政治的自殺行為につながるからだ。
意識したいrmaruon.icon
6章 ユーザーも人間
ソフトウェアのユーザーを集めたいのであれば、ソフトウェアに対する感情的な知覚に配慮しなければいけない。
意識したいrmaruon.icon
「速度は機能だ」
コードを書く側の都合ではなく、ユーザーに集中しよう。コードを書くのが大変になったとしても、愚痴を言わずにやるべきだ。
「速度向上は見込めません」とか「そんな難しい画面は作れません」とかを誰かがユーザーに突きつけているのを見聞きしたことがあるが、それは開発者のエゴだよなぁと強く思うrmaruon.icon 複雑なことであっても、簡単なことをしているように感じられるようにするべき
ユーザーのデータにはアクセスできるようにすべきだ。
自分がアプリケーションを作るときは意識したいrmaruon.icon
ユーザーの意見は直接聞いたほうがいい。パブリックなバグ管理ツールを用意して、苦情があればそこに書き込んでもらうのだ。
ユーザーとやり取りをしたくないのは、ユーザーのことをバカだと思っているからである。
コンピュータを扱う能力が高ければ、一般的知能が優れているわけではない。
多くの人にとってコンピュータ(や君のソフトウェア)はブラックボックスである。
その人が言っていることを文字通りに解釈するのではなく、何を意図しているかを理解することが重要なスキルになる。
ユーザーとの関わりも書いてあるなんて、素晴らしい本だ
同意しかない
そのソフトウェアは君のためではない。チームのためではない。会社のためではない。ユーザーの生活を豊かにするためである。
1章 天才プログラマの神話
1.1 コードを隠して
1.2 天才の神話
1.3 隠したらダメになる
1.4 チームがすべて
1.5 三本柱
1.6 実践 HRT
1.6.1 エゴをなくす
1.7 批判の配分と対応を学ぶ
1.7.1 早い段階で失敗・学習・反復する
1.7.2 学習のための時間を残す
1.7.3 忍耐を学ぶ
1.7.4 影響を受けやすくする
1.8 次のステップ
2章 素晴しいチーム文化を作る
2.1 文化とは何か
2.2 なぜ気にかける必要があるのか?
2.3 文化と人々
2.4 成功する文化のコミュニケーションパターン
2.5 ハイレベルの同期
2.5.1 ミッションステートメント(いや、マジで)
2.5.2 効率的なミーティング
2.5.3 「地理的障害」のあるチームで働く
2.5.4 設計文書
2.6 日常的な議論
2.6.1 メーリングリスト
2.6.2 オンラインチャット
2.7 課題管理ツールを使う
2.8 エンジニアリングとしてのコミュニケーション
2.8.1 コードコメント
2.8.2 ソースコードに名前を書く(別名:「Authorタグ」問題)
2.8.3 すべてのコミットにコードレビュー
2.8.4 リアルなテストとリリースプロセス
2.9 すべてはコードに通ず
3章 船にはキャプテンが必要
3.1 自然は真空を嫌う
3.2 @Deprecatedマネージャー
3.2.1 「リーダー」は新しい「マネージャー」
3.2.2 1つだけ怖いのは ……まあ、全部だ
3.3 サーバントリーダー
3.4.1 アンチパターン:自分の言いなりになる人を採用する
3.4.2 アンチパターン:パフォーマンスの低い人を無視する
3.4.3 アンチパターン:人間の問題を無視する
3.4.4 アンチパターン:みんなの友達になる
3.4.5 アンチパターン:採用を妥協する
3.4.6 アンチパターン:チームを子どもとして扱う
3.5 リーダーシップパターン
3.5.1 エゴをなくす
3.5.2 禅マスターになる
3.5.3 触媒になる
3.5.4 先生やメンターになる
3.5.5 目標を明確にする
3.5.6 正直になる
3.5.7 幸せを追い求める
3.5.8 その他のヒントやトリック
3.6 人は植物
3.7 内発的動機と外発的動機
3.8 最後に
4章 有害な人に対処する
4.1 「有害」の定義
4.2 チームを強化する
4.3 脅威を特定する
4.3.1 他人の時間を尊重しない
4.3.2 エゴ
4.3.3 権利を与えすぎる
4.3.4 未熟なコミュニケーションと複雑なコミュニケーション
4.3.5 パラノイア
4.3.6 完ぺき主義
4.4 有害な人を追い出す
4.4.1 完ぺき主義者には別の方向性を示す
4.4.2 生命体にエサを与えない
4.4.3 感情的にならない
4.4.4 不機嫌の真実を探せ
4.4.5 優しく追い出す
4.4.6 諦めるときを知る
4.4.7 長期的に考える
4.5 最後に
5章 組織的操作の技法
5.1 善玉、悪玉、戦略漢
5.2 理想:チームがうまく機能している会社
5.2.1 理想的なマネージャー
5.3 現実:環境が成功の邪魔になっているとき
5.3.1 悪いマネージャー
5.3.2 オフィスの政治家
5.3.3 悪い組織
5.4 組織を操作する
5.4.1 許可を求めるより寛容を求めるほうが簡単
5.4.2 道がないなら道を作る
5.4.3 上司の管理方法を学ぶ
5.4.4 運と親切の経済
5.4.5 安全なポジションまで昇進する
5.4.6 強力な友達を探す
5.4.7 忙しい経営者に(メールで)お願いする方法
5.5 プラン B:逃げる
5.6 希望は残されている
6章 ユーザーも人間
6.1 一般認識を管理する
6.1.1 第一印象に注目する
6.1.2 小さく約束して、大きく届ける
6.1.3 業界のアナリストと付き合う
6.2 君のソフトウェアはどれだけ使いやすいだろうか?
6.2.1 観客を選ぶ
6.2.2 ハードルを下げる
6.2.3 ユーザーではなく利用を計測する
6.2.4 速度重要
6.2.5 いろいろ手を出さない
6.2.6 怠けない
6.2.7 複雑さを隠す
6.3 ユーザーとの関係を管理する
6.3.1 見下さない
6.3.2 我慢する
6.3.3 信頼と喜びを作る
6.4 ユーザーのことを忘れない